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ABSTRACT 

In  this  paper1,  we  present  a  case  study  of  emulation  workflow 
in  tactical  wireless  mobile  network.  The  main  contribution  of 
this  paper  is  an  XML  schema  which  has  been  recently 
developed  by  the  Naval  Research  Laboratory’  (NRL)  to 
support  high  level  scenario  definition  for  mobile  netM’ork 
emulators  in  a  tool  independent  manner.  In  the  scenario 
definition  phase,  a  high  level  mobility  scenario  defined  using 
the  NRL's  XML  schema  is  converted  to  WISER' s  run-time 
emulation  files.  Using  the  nodes’  locations  and  terrain 
information,  the  RF  module  performs  the  relevant  calculations 
and  outputs  a  topology  script  that  depicts  node  positions  and 
link  characteristics  (i.e.  bandwidth,  BER)  for  all  node  pairs. 
To  demonstrate  emulation  scenario  definition  workflow, 
Dynamic  Routing  Control  Agent  (DRCA)  along  with  the 
snapshot  generation  tool  is  selected  as  a  case  study.  DRCA, 
which  is  a  run-time  agent,  monitors  network  topology,  traffic 
and  capacity  and  sets  the  OSPF  link  metrics  dynamically  to 
control  routing  paths.  A  snapshot  generation  tool  is  integrated 
with  the  WISER  SDT  to  identify  significant  changes  in  the 
netw’ork.  An  objective  is  to  identify  a  small  but  representative 
set  of  snapshots  that  capture  all  of  the  key  changes  in  network 
topology  over  the  course  of  a  scenario.  The  above  mentioned 
tools,  which  are  integrated  within  the  WISER  SDT,  are  used  to 
define  and  analyze  DRCA  scenarios  for  the  WISER  emulation 
system.  EMANE  emulation  workflow  is  also  described  to 
demonstrate  that  the  NRL ’s  emulation  script  schema  can  be 
used  to  define  scenarios  in  a  tool  independent  manner. 

INTRODUCTION 

Network  emulation  and  simulation  tools  have  been  widely 
used  in  research  and  development  of  mobile  ad  hoc  network 
(MANET)  architectures  and  protocols.  These  systems  provide 
not  only  a  cost  effective  infrastructure  in  terms  of  hardware 
resources;  they  also  ensure  efficiency  in  terms  of  human 
power  needed  to  test  and  evaluate  the  network  performance 
under  various  conditions  before  the  field  testing  and  actual 
deployment.  A  variety  of  network  emulators  and  simulators 
(e.g.,  WISER  [4],  EMANE  [2],  Qualnet,  ns-2,  OPNET) 
provide  a  rich  set  of  tools  and  models  to  conduct  customized 
experiments. 

Each  of  these  platforms  has  different  capabilities  and  features. 
Unfortunately  there  is  not  one  single  platform  that  can  be  used 
exclusively  to  study  the  network  performance;  hence,  it  is 
common  that  one  might  need  to  work  with  a  multitude  of 
tools.  For  example,  we  use  WISER,  EMANE,  and  OPNET  for 
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the  research  and  development  of  Telcordia’s  Dynamic  Routing 
Control  Agent  (DRCA)  for  various  reasons.  The  OPNET 
simulator  is  used  to  study  the  DRCA  parameters  under  various 
network  conditions  since  OPNET  has  highly  advanced 
scenario  generation  and  performance  analysis  tools.  Scenarios 
with  different  DRCA  parameters  can  be  conveniently 
generated  and  scheduled  to  run  overnight.  However, 
simulation  tools  typically  do  not  run  in  real  time  and  rely  on 
simplified  models  rather  than  a  real  system. 

WISER  and  EMANE  platforms  provide  high-fidelity  network 
modeling,  exchange  packets  in  real-time,  and  faithfully 
capture  the  complexity  of  interactions  among  different 
network  entities.  WISER  is  used  for  the  DRCA  development 
since  it  supports  ground-to-ground  (HNW-like)  and  ground- 
to-satellite  (NCW-like)  TDMA  MAC  algorithms  and  provides 
automated  routing  protocol  configurations  for  XORP  [2]. 
These  MACs  are  not  available  for  EMANE  as  of  the  writing 
of  this  paper.  Moreover,  WISER’ s  packet  forwarding  and 
MAC  emulation  modules  run  in  the  kernel  space,  and  hence 
provide  significant  performance  improvements  for  emulating 
large  sized  networks.  EMANE  is  used  for  the  DRCA 
development  since  the  open  source  quagga  routing  suite  [6], 
which  supports  OSPFv2  with  Multi  Topology  Routing  (MTR) 
and  OSPFv3  with  MANET  extensions,  can  be  run  in  the 
EMANE  testbed.  These  routing  protocols  are  planned  to  be 
used  in  DRCA’s  target  network  environment  which  is 
currently  being  developed  under  the  DTCN  program. 

Mobile  network  emulation  scenarios  have  many  common 
features.  For  example,  each  scenario  has  to  define  network 
properties  such  as  number  of  nodes,  area  boundaries,  terrain; 
node  and  link  properties  such  as  vehicle  type,  speed,  role  on 
the  scenario,  radio  capabilities  and  antenna  settings,  IP  address 
configuration.  Defining  nodes’  locations  and  their  mobility 
patterns  over  the  course  of  emulation  is  an  essential  part  of  the 
scenario  definition  for  MANET.  Finally,  each  emulation 
scenario  has  to  define  application  traffic  types  (e.g.,  UDP, 
TCP,  VoIP,  etc.)  and  their  characteristics  (e.g.,  duration,  rate, 
inter-arrival  times,  etc.).  Although  there  are  many  common 
properties,  each  emulation  tool  has  its  own  scenario  definition 
format.  The  user  has  to  spend  considerable  time  to  replicate 
the  scenario  under  test  for  different  platforms,  especially  in 
case  of  complex  scenarios.  The  ability  to  define  scenarios  in  a 
tool  independent  manner  is  highly  desirable  in  the  networking 
community. 

In  this  paper  we  present  a  generalized  Emulation  script 
schema,  which  has  been  recently  developed  by  NRL  [1].  The 
scenarios  defined  according  to  this  schema  can  be  translated  to 
multiple  emulation  systems  with  the  appropriate  tools.  The 
system  independent,  common  scenario  definition  allows  the 
user  to  utilize  the  same  scenario  in  different  systems.  This 
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would  also  enable  the  networking  community  to  define 
benchmark  scenarios.  The  scenarios  defined  according  to  the 
NRL  Emulation  script  schema  are  converted  to  the  WISER 
run-time  emulation  files.  The  standalone  version  of  DRCA 
along  with  the  snapshot  generation  tool  is  used  as  a  scenario 
definition  workflow  case  study. 

NRL  EMULATION  SCRIPT  SCHEMA 

The  Emulation  script  schema  is  an  XML  schema  that  supports 
elements  to  define  certain  mobile  node  characteristics  (e.g. 
location,  velocity,  orientation,  etc.)  and  parameters  of  other 
functional  modules  and  changes  to  those  characteristics  or 
parameters  over  the  course  of  mobile  network  modeling 
experiment.  This  schema  adopts  a  modular  approach  to  the 
definition  of  mobile  network  modeling  scenarios.  A  couple  of 
categories  of  document  types  comprise  this  modular  approach: 
"Planning  Documents"  and  "Emulation  Script  Documents". 
Figure  1  illustrates  this  modular  approach  of  planning 
documents  that  can  be  created  to  separately  describe  different 
aspects  of  the  scenario  and  script  documents  that  are  the 
resulting  composite  of  the  separate  planning  components.  The 
Emulation  script  documents  contain  time-ordered  events  that 
tightly  script  (i.e.,  dynamically  update)  emulation  module 
properties  (e.g.,  node  location/motion  and  others).  The 
planning  documents  allow  aspects  of  the  scenario  to  be 
preplanned  in  a  more  tenable,  natural  fashion.  For  example,  a 
"MotionPlan"  document  type  is  an  example  of  a  planning 
document  that  lets  a  user  describe  the  intended  motion  plans 
for  mobile  nodes  in  the  scenario  in  a  somewhat  natural  fashion 
(e.g.,  start  at  a  certain  location,  move  to  first  waypoint,  then 
another,  etc.).  Additional  planning  document  types  such  as 
"NetworkPlan"  and  "CommunicationPlan"  types  convey 
network  system  and  node  configuration  and  communication 
events,  respectively.  The  blue  portions  of  Figure  1  correspond 
to  the  components  of  the  planning  and  experiment 
orchestration  process  that  can  be  somewhat  independent  of  the 
target  mobile  network  modeling  system.  The  red  portions  are 
those  components  that  need  to  have  specific  knowledge  of  the 
target  system.  The  template  file  provides  an  input  to  the 
system  configuration  process  that  can  be  used  to  control 


parameters  of  how  the  specific  modeling  system  is  to  be  set  up 
or  used.  The  generation  of  the  system  configuration  file(s)  is  a 
synthesis  of  the  generic  planning  documents  and  this  template. 
The  "EmulationDirectory"  document  provides  a  mapping  of 
the  generic  scenario  elements  (e.g.,  nodes  and  their  interfaces) 
to  the  instantiations  of  emulation  system  components  (e.g., 
EMANE  Network  Emulation  Modules  (NEMs),  ns-2 
simulation  agents,  etc.)  that  represent  those  elements.  The 
"EmulationDirectory"  document  then  provides  a  reference  to 
map  scripted  scenario  configuration  events  to  specific  run¬ 
time  events  or  commands  for  the  specific  modeling  system(s) 
in  use.  Similarly,  run-time  control  events  are  generated  as  a 
synthesis  of  the  scripts  that  result  from  the  processing  of 
planning  documents  and  the  specific  system  configuration  that 
was  created.  The  purple  coloring  of  the  "EmulationDirectory" 
document  and  "Event  Generator"  functional  module  illustrates 
their  incorporation  of  both  the  blue  generic  scenario 
description  and  red  system-specific  configuration  information. 
The  Emulation  script  XML  schema  enables  the  use  of  existing 
and  emerging  XML  content  manipulation  tools  to  perform 
operations  on  scripts.  This  includes  filtering  of  events  within 
scripts,  potential  merging  of  scripts,  and  manipulations  that 
might  parametrically  alter  a  script.  This  schema  is  also 
designed  to  allow  for  conversion  to  and  from  other  file 
formats  as  needed.  This  ability  to  provide  translation 
compatibility  with  other  formats  can  make  this  schema  useful 
for  specifying  and/or  scripting  scenarios  outside  of  strictly 
emulation  purposes,  including  use  with  tools  for  discrete  event 
network  simulation  (e.g.  ns-2,  OPNET,  etc.)  or  for  analytical 
programs.  The  structure  of  the  schema  attempts  to  be 
sufficiently  general  to  contain  XML  elements  that  allow 
inclusion  of  events  that  can  initialize  or  update  characteristics 
of  any  modules  within  the  emulation  system.  This  generalized 
capability  will  allow  users  to  construct  scripts  that  can 
describe  alterations  to  arbitrary  aspects  of  the  emulation  over 
time  (provided  that  the  run-time  framework  supports 
interpretation  of  these  events  and  control  of  those  aspects).  To 
demonstrate  that  the  proposed  schema  can  be  used  in  a  tool 
independent  manner,  we  will  present  the  workflow  for  two 
emulation  systems:  EMANE  and  WISER. 


Planning  Documents 
(e.g.  “MotionPlans”, 


Figure  1  Emulation  Planning  and  Scripting  Work  Flow 
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EMULATION  WORKFLOW  FOR  EMANE 

A  rich  set  of  tools  as  depicted  in  Figure  2  has  been  developed 
by  NRL  to  generate  and  manipulate  the  EMANE  scenarios 
based  on  the  Emulation  script  schema.  These  tools  are 
displayed  in  blue  in  Figure  2.  The  motion  plan  ( mp )  tool 
converts  the  MotionPlan  document  into  an  intermediate 
EmulationScript  document  which  includes  location  and 
motion  events.  The  enp  tool  gets  NetworkPlans, 
EmaneTemplate,  and  EmulationsScript  (generated  by  mp) 
documents  as  input  and  generates  the  final  EmulationScript 
and  EmulationDirectory  files,  and  the  EMANE  "platform.xml" 
configuration  file.  The  next  step  is  to  use  motion  generator 
(mg)  tool  to  generate  an  EMANE  EEL  (emulation  event  log) 
file  with  location  events  (and  possibly  some  network 
configuration  and/or  interface  parameter  events).  The  graph 
builder  (gb)  tool  takes  the  EEL  file  as  input  and  optionally  a 
terrain  data  file  to  calculate  and  add  "pathLoss"  events  to  the 
given  EEL  file.  Finally,  an  EMANE  experiment  can  be  run 
with  the  given  configuration  files  and  the  EEL  file.  It  should 
be  noted  that  utilities  are  available  that  can  convert  to  and 
from  different  mobility  file  formats  like  SDT,  MMF,  EEL  and 
ns-2  setdest.  This  allows  the  output  of  the  workflow  chain  to 
be  used  for  different  systems. 

EMULATION  WORKFLOW  FOR  WISER  WITH 
SCENARIO  ANALYSIS  TOOLS 

In  this  section  we  demonstrate  how  the  Emulation  Script 
schema  can  be  used  for  defining  a  WISER  scenario.  Figure  3 
shows  an  overview  of  the  emulation  workflow  which  consists 
of  four  steps:  scenario  definition,  RF  analysis,  snapshot 
generation,  and  route  analysis.  These  steps  are  integrated  into 
Scenario  Definition  Tool  (SDT)  of  WISER  which  provides 
high-fidelity  network  modeling,  exchanges  packets  in  real¬ 
time,  supports  a  flexible  open  source  router  platform  (XORP), 
and  offers  TDMA-based  wireless  MAC  emulation  capabilities 
for  different  types  of  links,  waveforms,  radio  devices.  Our 


objective  is  to  define  scenarios  for  DRCA  testing  using  the 
NRL’s  tool  independent  emulation  script  schema  and  analyze 
and  refine  the  scenarios  before  running  them  in  the  real 
emulation  system. 

In  the  scenario  definition  phase,  two  files  are  input  to  the 
WISER  SDT,  a  motion  plan  document  and  a  WISER  template 
file.  The  NRL  motion  plan  document  is  used  to  define  the 
nodes’s  initial  locations  and  mobility  patterns.  WISER  assigns 
network  configuration  in  an  automated  way  and  RF  properties 
like  fading,  shadow  loss,  path  loss  model,  bit  error  ratio 
(BER),  etc  are  defined  from  the  SDT  on  a  scenario  wide  basis. 
Hence,  the  “NetworkPlan”  and  “CommunicationPlan” 
documents  in  Figure  1  are  not  used  in  this  case.  The  WISER 
template  file  corresponds  to  the  System  Configuration 
Template  and  contains  information  specific  to  the  SDT  such  as 
node  type,  satellite  capability,  interface  type,  etc.  The 
MpToSdt  tool  is  analogous  to  the  “mp”  tool  shown  in  Figure  2. 
It  converts  a  high  level  mobility  scenario  defined  by  the  NRL's 
Motion  plan  to  WISER's  input  file  which  includes  the  nodes’ 
initial  locations  and  their  movements  using  the  waypoint 
primitives.  Using  the  nodes’  locations,  terrain  information, 
and  the  RF  parameters,  the  RF  module  performs  the  relevant 
calculations  and  outputs  an  emulation  scenario  script  that 
depicts  node  positions  and  link  characteristics  (i.e.  bandwidth, 
BER)  for  all  node  pairs  over  the  course  of  emulation.  This 
script  includes  a  time  ordered  emulation  scenario  that  can  be 
played  on  the  GUI  or  run  on  the  emulation  test  bed.  DRCA 
along  with  the  snapshot  generation  tool  is  selected  as  the 
emulation  case  study.  The  standalone  version  of  DRCA  is 
integrated  with  the  WISER  SDT  to  analyze  the  scenarios  in 
terms  of  routing  and  link  utilizations.  A  snapshot  generation 
tool  is  integrated  with  the  WISER  SDT  to  identify  a  small  but 
representative  set  of  snapshots  that  capture  all  of  the  key 
changes  in  network  topology  over  the  course  of  a  scenario. 
These  steps  will  be  described  in  detail  in  the  following 
subsections. 
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Figure  3  Emulation  Case  Study  Workflow  for  WISER  using  NRL  Motion  Plan 


SCENARIO  DEFINITION  USING  NRL  MOTION 
PLAN 

As  described  earlier  in  the  paper,  the  MotionPlan  document 
lets  the  user  describe  the  intended  motion  patterns  for  nodes  in 
a  natural  fashion.  This  is  achieved  by  specifying  complex 
motion  as  a  concatenation  of  primary  motion  primitives.  The 
tools  can  then  convert  these  complex  motion  primitives  to  the 
time  ordered  representation  required  for  run  time  motion 
generation.  Furthermore,  sequences  of  motion  primitives  can 
be  encapsulated  as  named  motion  patterns  and  those  patterns 
can  be  re-used  by  reference  to  specify,  possibly  repetitive, 
node  motion  or  as  part  of  more  complex  pattern  definition.  In 
the  simple  MotionPlan  example  in  Figure  4,  a  loop  pattern  is 
defined  that  consists  of  a  triangle  of  three  waypoints.  The 
nodeOl  motion  plan  is  specified  with  an  initial  location  and 
pause  of  120.0  seconds  followed  by  the  triangle  loop  pattern 
with  an  undefined  number  of  repeats,  but  limited  to  duration 
of  600.0  seconds.  After  the  600.0  seconds  of  time  spent  in  the 
loop,  the  node  traverses  to  a  specified  waypoint  and  begins 
another  120.0  second  pause.  After  this  pause,  nodeOl  finally 
enters  into  a  30  meter  radius  circle  motion  pattern  for  an 
indefinite  time.  The  primary  motion  primitives  include 
waypoint,  vector,  location,  circle,  pause,  loiter  and  randpoint. 
The  motion  primitives  also  have  a  duration  attribute  that  can 
be  set  to  specify  time  limits  for  each  primitive  to  pace  the 
execution  of  the  concatenated  set  of  motion  primitives.  The 
location  primitive  specifies  immediate  re-location  (i.e., 
teleportation)  to  specified  coordinates.  The  waypoint  primitive 
specifies  a  destination  towards  which  the  node  should  move  at 
specified  velocity.  The  vector  primitive  specifies  a  direction, 
given  in  azimuth  and  optional  elevation  angles  at  which  the 
node  should  move  at  specified  velocity.  The  circle  primitive 
is  used  specify  motion  along  the  perimeter  of  a  circle  of  a 
specified  radius  about  a  center  location  at  a  given  velocity. 
The  circle  also  has  an  optional  revs  element  that  indicates  the 
maximum  number  (or  fractional  number)  of  circle  revolutions 
to  complete  before  motion  is  completed.  The  loiter  primitive 
is  provided  to  specify  a  circular  (hovering  or  loitering)  motion 
that  is  relative  to  another  embedded  motion  primitive  or 
pattern.  The  randpoint  primitive  can  be  used  to  generate 
randomly  selected  node  waypoints  or  locations.  Each  time  a 
randpoint  primitive  is  processed  it  may  generate  a  random 
waypoint  or  location  within  the  bounding  location  box,  time, 
and  speed.  The  pause  primitive  element  is  provided  to  specify 
intervals  of  immobility  from  the  completion  of  a  prior  motion 
primitive  or  pattern  before  beginning  transition  to  a 
subsequent  motion  primitive  or  pattern.  The  pattern  primitive 
identifies  (by  name)  a  motion  sequence  that  was  previously- 


defined  using  the  “PatternDefmition”  element.  The  pattern 
element  also  has  an  optional  repeat  attribute  that  can  be  used 
to  indicate  how  many  times  the  motion  sequence  should  repeat 
before  proceeding  to  any  subsequent  motion. 

The  WISER  SDT  input  file  only  allows  node  motion  in  the 
form  of  waypoints.  The  MpToSdt  tool  therefore  implements 
these  complex  motion  patterns  as  a  set  of  concatenated 
waypoints.  This  approach  shows  that  even  if  the  target  system 
does  not  support  a  particular  feature  defined  by  the  Emulation 
script  schema,  the  system  specific  tools  can  be  designed  in 
such  a  way  as  to  result  in  the  intended  scenarios. 

<MotionPlan> 

<PatternDefinition  name="loop"> 

<waypoint> 

<destination>  latl,  lonl,  altl</> 

<velocity>12.0</> 

</waypoint> 

<waypoint> 

<destination>  Iat2,  lon2,  alt2</> 

<velocity>12.0</> 

</waypoint> 

<waypoint> 

<destination>  Iat3,  lon3,  alt3</> 

<velocity>12.0</> 

</waypoint> 

<waypoint> 

<destination>  latl,  lonl,  altl</> 

<velocity>12.0</> 

</waypoint> 

</PatternDefinition> 

<Node  name="node01"> 

<location>  Iat0,lon0,alt0</Iocation> 

<pause>120.0</pause> 

<pattern  repeat="-l"  duration=''600.0">loop</pattern> 
<waypoint> 

<destination>lat4,lon4,alt4</> 

<velocity>20.0</> 

</waypoint> 

<pause>120.0</> 

<circle> 

<center>lat5,lon5,alt5</> 

<radius>30.0</> 

<velocity>15.0</> 

</circle> 

</Node> 

</MotionPlan> 

Fig  4  Motion  Plan  Example 
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RF  ANALYSIS 

With  the  NRL  Motion  Plan  and  WISER  template  files  merged 
in  the  above,  the  scenario  is  next  fed  through  the  RF  module  to 
compute  a  realistic  physical  layer  representation.  To 
determine  ground-to-ground  connectivity,  the  RF  module 
computes  the  Symbol  Energy  to  Noise  Density  Ratio  ( Es/N0 ) 
for  all  node  pairs  per  a  configurable  time  interval  [5].  The 
E/N0  is  then  used  as  an  index  for  table-lookup  into  target  radio 
specifications,  providing  the  expected  symbol  coding  and 
modulation  rates  applied.  An  additional  look-up  calculation 
then  converts  the  coding  and  modulation  rates  to  yield  typical 
bandwidth  and  bit-error-ratio  under  these  conditions. 

The  Es/Na  calculation  requires  its  own  set  of  inputs  extracted 
from  the  WISER  scenario  file.  First,  path  loss  between  all 
node  pairs  is  computed  using  antennae  settings  and 
instantaneous  node  positions.  Path  loss  models  include  terrain 
data  (i.e.  TIREM)  or  theoretical  models  such  as  exponent- 
based  propagation  with  a  configurable  Path  Loss  Exponent 
(PLE)  parameter.  Next,  shadowing  effects  are  applied  using 
constant  or  log-normally  distributed  models.  Finally,  Rayleigh 
fading  based  on  Effective  SINR  Mapping  further  attenuates 
the  signal.  The  ground-to-satellite  RF  model  follows  a  similar 
procedure  to  that  of  ground-to-ground  RF,  however  it 
computes  the  Carrier  to  Noise  Ratio  ( C/Na )  instead  of  E/Nm 
follows  free  space  path  loss,  and  applies  atmospheric 
absorption  models  for  further  accuracy. 


SNAPSHOT  GENERATION 


In  this  stage,  the  scenario  time  line  is  sliced  into  multiple 
phases,  each  summarized  by  a  snapshot  that  characterizes  the 
state  of  the  network.  The  term  “snapshot”  is  used  here  for 
descriptive  purposes  to  connote  the  notion  of  capturing  the 
network  state  at  a  particular  point  in  time.  A  snapshot 
generation  tool  is  integrated  with  the  WISER  SDT  to  identify 
a  small  but  representative  set  of  snapshots  that  capture  all  of 
the  key  changes  in  network  topology  over  the  course  of  a 
scenario.  Clearly,  one  of  the  tradeoffs  in  snapshot 
identification  is  the  number  of  snapshots  to  be  computed. 
That  is,  allowing  more  snapshots  potentially  increases  the 
fidelity  of  capturing  changes  in  the  network  state  at  the 
expense  of  increased  computation  delay  when  these  snapshots 
are  analyzed  (e.g.,  route  analysis  by  DRCA). 


Figure  4  Initial  snapshot  at  time=0 


The  snapshot  identification  approach  has  two  configurable 
options:  (i)  create  snapshots  by  sampling  the  mission  timeline 
at  a  regular  interval,  (ii)  apply  the  counts  of  various  event 
classes  (including  node/link  arrivals  and  departures)  as  the 
main  snapshot  discriminator.  In  the  interval-based  snapshot 
identification,  the  mission  timeline  is  sampled  at  a  regular 
interval.  With  the  number  of  snapshots  specified  as  a 
configuration  parameter,  the  time  interval  is  determined  from 
the  total  scenario  time  and  the  number  of  snapshots.  In  Option 
(ii),  the  procedure  identifies  a  new  snapshot  when  two 
conditions  hold:  (i)  the  number  of  events  counted  from  the 
start  of  the  current  snapshot  exceeds  a  given  threshold,  and  (ii) 
the  time-distance  between  the  last  event  in  the  current 
snapshot  and  the  earliest  next  event  exceeds  a  given  threshold. 

ROUTE  ANALYSIS  (DRCA) 

After  the  snapshots  are  generated,  each  snapshot  is  analyzed 
using  the  standalone  version  of  DRCA  [7],  where  the  DRCA 
input  files  are  obtained  from  the  scenario  definition  tool.  In  the 
actual  deployment  of  DRCA  as  a  run-time  agent,  the  network 
topology  is  extracted  from  the  Link  State  Database  (LSDB) 
while  local  DRCA  agents  running  at  every  node  measure  the 
traffic  and  link  capacity  information  and  report  this 
information  to  the  Lead  DRCA  analyzer  for  new  link  weights’ 
calculations.  DRCA  has  been  running  in  COTS  router, 
WISER,  and  EMANE  testbeds,  and  OPNET  as  well. 

For  each  scenario,  the  DRCA  GUI  is  used  to  visualize  the 
network  information  and  conditions  at  a  particular  snapshot. 
For  example,  the  GUI  shows  the  network  topology,  link 
capacities,  routing  paths,  link  utilizations,  throughput, 
congested  links,  and  more.  In  the  analysis  heuristics,  DRCA 
dynamically  computes  OSPF  link  metrics  to  achieve  the  user 
specified  objectives  based  on  the  network  topology,  traffic 
demand  and  link  capacities  and  transmission  delays  of  the 
network.  The  WISER  emulation  script  instances 
corresponding  to  the  snapshots  are  converted  to  the  DRCA 
input  files  (e.g.,  topology  and  link  capacity  files).  Another 
important  scenario  element  for  DRCA  is  the  traffic  demand 
matrix  which  contains  the  amount  of  traffic  among  all  node 
pairs  in  the  network.  As  described  below,  the  traffic  matrix  is 
randomly  generated  and  scaled  up/down  to  obtain  different 
network  loading  (light,  medium,  and  heavily  loaded 
networks). 


Figure  5  Third  snapshot  at  time=197  seconds 


2420 


5 


Table  1  The  network-wide  packet  loss  percentages  w/o  and  w/  DRCA 


T 

2T 

3T 

4T 

N 

w/o 

w/ 

w/o 

w/ 

w/o 

w/ 

w/o 

w/ 

PLE=2.15 

5.01 

0 

0 

1.34 

0 

6.65 

3.69 

14.23 

13.17 

PLE=2.20 

3.51 

3.15 

0 

23.30 

15.36 

37.99 

34.61 

47.59 

46.54 

EXAMPLE  SCENARIOS  AND  RESULTS 

In  this  section,  we  present  numerical  results  to  demonstrate  the 
complete  emulation  scenario  definition  workflow  for  WISER. 
A  similar  workflow  has  been  implemented  for  EMANE; 
however,  due  to  the  space  limit  we  will  not  include  any  result 
here.  First,  a  MotionPlan  document  is  generated  for  a  15-node 
scenario,  where  each  node’s  movement  pattern  can  be  seen  in 
Figure  4  and  Figure  5.  The  scenario  duration  is  600  seconds. 

In  the  RF  module,  two  different  Path  Loss  Exponents  (PLEs) 
of  2.15  and  2.20  are  used.  As  Table  1  shows,  the  average 
number  of  neighbors  (N)  is  5.01  and  3.51  for  the  PLEs  of  2.15 
and  2.20,  respectively.  Figure  4  shows  initial  locations  and 
Figure  5  shows  the  third  snapshot  at  time  197  seconds,  both 
for  the  PLE  of  2.20.  The  same  NRL  MotionPlan  document  is 
used  for  both  PLEs. 

For  each  PLE  scenario,  the  snapshot  generation  tool  using  the 
same  parameters  is  run.  The  minimum  and  maximum  number 
of  events  to  generate  a  new  snapshot  as  a  percentage  of  the 
total  events  are  0.2  and  0.4,  respectively.  The  minimum  time 
difference  between  snapshots  is  set  to  40  seconds.  Our 
snapshot  identification  algorithm  uses  the  counts  of  link 
arrival  and  departure  events.  The  snapshot  generation  tool 
yields  4  snapshots  for  the  scenario  with  the  PLE  of  2.15  while 
5  snapshots  for  the  scenario  with  the  PLE  of  2.20  (excluding 
the  initial  snapshots).  The  snapshot  times  for  the  PLE  of  2.15 
are  71,  121,  197,  and  338  seconds.  For  the  traffic  generation, 
each  node  randomly  selects  4  destinations  and  generates 
Constant  Bit  Rate  (CBR)  traffic  (i.e.,  60  sessions)  to  their 
selected  destinations.  For  example,  in  Table  1,  T  corresponds 
to  a  traffic  rate  of  one  unit  per  second  between  each  source 
and  destination  pair  and  2T  corresponds  to  2  units  per  second, 
and  so  on. 

Table  1  shows  the  network-wide  traffic  loss  percentages 
averaged  over  all  snapshots  for  each  PLE  scenario.  Although 
there  are  other  results  available  in  the  DRCA  GUI  (e.g.,  the 
link  utilization  ratios,  traffic  loading,  etc.),  the  network-wide 
loss  percentages  are  selected  as  an  example.  The  parameter 
PLE  in  the  RF  module  has  significant  impacts  on  the  network 
density  (i.e.,  average  number  of  neighbors)  and  hence  the 
network-wide  traffic  loss  percentages.  For  example,  the  traffic 
demand  matrix  of  T  yields  no  traffic  loss  for  the  case  with  the 
PLE  of  2.15  while  it  causes  3.15%  traffic  loss  for  the  PLE  of 
2.20  using  the  default  link  weights  (i.e.,  hop  counts  for  the  w/o 
DRCA  case).  The  same  observation  is  valid  for  all  the  other 
traffic  demand  matrices  in  Table  1.  The  traffic  loading  level 
has  significant  effects  on  the  DRCA  optimization  performance 
such  that,  for  the  heavily  loaded  networks  (4T  for  the  PLE  of 
2.15  and  3T  and  4T  for  the  PLE  of  2.20),  the  DRCA 
throughput  improvements  are  minimal  since  there  is  less  likely 
to  have  underutilized  alternative  paths  for  rerouting  in  the 
highly  loaded  networks.  In  other  words,  no  alternative  paths 


with  sufficient  link  capacities  exist  since  all  link  capacities  are 
almost  fully  utilized  for  the  heavily  loaded  networks.  For  the 
lightly  and  medium  loaded  networks  ( T ,  2T,  and  37'  for  the 
PLE  of  2.15  and  T  and  2T  for  the  PLE  of  2.20),  the  DRCA 
provides  significant  performance  improvements  (from  about 
%34  less  traffic  loss  to  no  loss  at  all).  This  confirms  that 
DRCA  can  provide  better  resource  utilizations  for  the 
operational  MANET  networks  since  they  are  usually  lightly 
and  medium  loaded  but  some  of  their  links  gets  congested  due 
to  sudden  changes  in  traffic  demand  and  link  capacities.  These 
example  scenarios  and  results  demonstrated  that  the  proposed 
emulation  scenario  definition  workflow  can  be  effectively 
used  to  define  and  analyze  the  DRCA  scenarios  for  the 
WISER  emulation  platform. 

CONCLUSION2 

In  this  paper,  we  presented  a  new  XML  schema  developed  by 
the  Naval  Research  Laboratory  to  support  high  level  scenario 
definition  for  mobile  network  emulators  in  a  tool  independent 
manner.  The  scenario  definition  emulation  workflows  for 
EMANE  and  WISER  platforms  along  with  the  supporting 
tools  are  described.  As  a  scenario  definition  case  study,  DRCA 
along  with  the  snapshot  generation  tool  is  integrated  with  the 
WISER  SDT.  The  scenarios  generated  using  the  NRL  schema 
are  converted  to  the  WISER  emulation  scripts  and  analyzed  by 
the  snapshot  generation  and  DRCA  tools.  The  proposed 
emulation  script  schema  along  with  the  supporting  tools  can 
be  effectively  used  to  define  benchmark  scenarios  for  the 
networking  community. 
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